精选TOP10｜电商大促万亿级数据稳定性保障解决方案
分享嘉宾：鲁天龙
阿里巴巴 数据安全生产平台技术专家。负责集团决策数据产品保障，包括数据质量、指标正确性、数据稳定性；担任部门双11、618大促PTM，组织决策数据产品、商家数据产品、平台数据产品的稳定性专项开展、风险识别与跟踪；负责部门数据安全生产，制定规范、建设工具能力，提升数据运维保障效率。
擅长领域：大数据质量测试、稳定性保障、治理
在上海站QECon全球软件质量&效能大会上，来自阿里巴巴的技术专家鲁天龙老师带来了关于《电商大促万亿级数据稳定性保障解决方案》的重要演讲。本文由鲁天龙老师根据会上演讲内容进行了详细整理和完善，欢迎感兴趣的小伙伴阅读、收藏、转发。
背景介绍
2020天猫双11销售额4982亿元，订单创建峰值达58.3万笔/秒，超过8亿消费者、25万品牌、500万商家共同参与。截止2022年3月31日，中国活跃消费者超10亿，全球活跃消费者已达13.1亿。这些概数背后，会有很多的分析和计算维度，维度叠加之下数据量非常庞大。目前阿里系各产品仅流量数据一天就到万亿级别。无论是日常的数据稳定性保障还是应对大促瞬时峰值的冲击，都存在非常大的挑战。
数据从客户端通过日志采集或者服务器记录上报，经过实时流式计算或者离线分布式计算加工，最终回流到数据库，通过数据服务，提供给对内的分析决策产品或者对外的品牌商家数据产品。
数据链路存在三个特点和风险：
数据量和计算量庞大。离线分布式计算每天处理的数据量超过万亿，实时流式计算峰值每秒链路上处理的数据量超过1亿。如果单个任务存在性能瓶颈或者集群整体的资源存在瓶颈，就会造成整个链路的任务延迟、任务报错，直观表现是数据产品里面看不到数据或者数据不更新。
大促前无真实活动数据。例如活动商品、活动标，在大促开始前业务系统中没有真实数据，这将导致数据逻辑、数据产品功能无法提前验证，最终将导致大促活动开始后，数据产品上的数据错误、甚至数据产品报错。
链路长依赖复杂。上图所示离线数据链路，平均依赖在20到60层，一个叶子任务节点上游可能有几千上万个任务，中间横跨多个部门团队。链路上任意一处小的变更，都可能引起下游的巨大变化，尤其在大促峰值场景下，影响面将进一步扩大。可能导致任务延迟、任务报错、数据出错等。
面对这样的特性和挑战，经过几年的探索和实践，我们沉淀了三个解决方案：数据全链路压测、数据应用提前预演、数据变更管控检测。在逐步解决问题的同时，不断进行工具化建设以提升效率控制成本。
数据全链路压测
1
实时流式计算压测
在这之前，实时流式计算全链路压测（以下简称实时压测）主要有单任务压测、集群缩容压测，但是都存在致命的缺点：无法模拟并验证上下游依赖稳定性、集群高负载性能、热点问题。通过改进之后，开始对整个集群进行模拟压测，但由于灌入的数据来自于日常，依然会存在以下问题：
数据密度差异。大促峰值时用户密度和商品密度比日常流量高很多；
用户行为差异。针对行为数据和成交数据，日常与大促差异较大；
数据覆盖度。日常没有活动数据、会场数据，压测不能覆盖到链路所有任务；
数据时效性。压测灌入数据时间分布和大促节奏不一致，数据失效；
流量叠加。压测灌入流量与上游写入流量叠加，出现流量过高的问题
实时压测目的是将机房性能、计算平台、存储系统、计算任务纳入压测范围，通过充分仿真大促态下用户行为，模拟出大促的访问流量，提前验证系统在目标峰值下的性能表现。
核心思路是以实时数据链路源头TT topic实际历史峰值数据为基础，进行数据膨胀和针对性流量补充。在源头TT topic符合流量峰值目标、大盘流量符合压测水位目标的前提下，实现对所有纳入压测范围的job流量覆盖。整体方案如下图所示：
这里涉及到5个关键点：
数据模型的选择。选择什么样的数据做压测
数据的膨胀与蓄洪。施压时间长历史大促峰值数据不够
施压引擎构建。满足不同峰值目标的施压速度
影子链路构建。压测产生的数据不能影响线上
维表替换。压测使用的数据与当前维度属性不匹配，数据全被过滤
1.1 数据模型的选择
选择历史峰值数据，可以覆盖大盘95%的流量，但仍有部分待压测job是最近新增或新变更，历史流量无法覆盖，需要对其进行流量补充。如果中间节点的输入TT有历史回流数据，可用于直接补充流量，如果中间节点为新业务，或无历史数据，可用线上流量实时补充。
1.2 数据的膨胀与蓄洪
既保持峰值数据模型，同时需要足够的数据量实现1个小时的阶梯压测，选择双十一峰值5分钟数据作为基础流量，并对其进行膨胀。简单的将数据复制膨胀会遇到以下两个问题：
引导场景的引导比例不能变。若加购与引导成交数据都翻倍，那么同一个人会有4组引导成交记录对。通过用户关系错位映射法解决：
订单号不能重复。重复单号会被数据链路过滤。通过最大差值叠加的方式来实现：
分析这段时间单号的最大差值
1.3 施压引擎构建
施压引擎核心要做的就是创建施压job，支持订阅压测流量的TT，并控速写入源头影子TT中，具备三个核心能力：
速率控制。最基本的需求，支持精确地实时调整下发流量的速率。
数据偏移。修改历史数据字段值，使其符合下游业务逻辑，如时间、单号修改等。
点位重置。压测时，可在不重启的情况下，调整消费点位，适配以下两种场景：
上一阶段压测结束但数据没有用完，则需要跳过去；
压测没有结束数据读取完了，可批量将所有TT调整到相同的逻辑点位，重新消费。
1.4 影子链路构建
影子链路的构建核心依赖全链路血缘分析，将压测范围内的所有任务以及其输入、输出进行拷贝，并统一命名规范。除了代码内容、输入输出以外，更重要的是将任务的配置全部复制，保证影子任务的运行性能与线上任务完全一致。
1.5 维表替换
维表替换，目的是为了让压测数据在实时系统中能和维表匹配上，否则压测流量将衰减很快，甚至直接过滤为0。
时间类型的字段，不可提前处理，需要在压测下发数据时，修改成当前时间。
商品类的数据，为了能在join时关联上，需要按照准备的压测数据对任务使用的维表做统一替换
实际的维表替换能力需要与影子链路构建能力打通，在影子任务生成时就已经按照要求替换好维表。
1.6 实时压测的应用实践
连续三年支持集团内多个BU业务包括天猫、淘宝、国际、文娱等大促实时流式计算全链路压测。集群问题100%拦截，任务性能问题95%提前发现。成本控制方面，施压成本从十几万降到几千元，压测准备从几天缩减到0.5天，全链路压测从几十人到只需要各个业务出一个接口人即可完成。
2
离线分布式计算压测
日志数据量从2018年突破万亿之后，仍在持续增长。在这之前，离线分布式计算压测（以下简称离线压测）手段往往是单个任务的性能评估，但存在成本和效率问题：
范围难以圈定。离线任务的数量有上百万个，没有那么多资源全部压测；
数据构造成本高。为每一个任务构造膨胀输入，消耗的资源和存储以及工作量十分庞大
影子链路构造复杂度高。调度依赖关系复杂，涉及的配置参数多，复制难度大
离线压测目的是快速构建影子链路、模拟数据膨胀、一键执行演练，提前发现潜在风险并优化、提高压测效率。
整体方案分为两个视角。业务接口人可以通过管理视角圈定压测范围、查看压测进度、汇总压测结果；数据任务owner可以通过简单的配置，完成压测任务选择、压测数据构造、影子链路构造、压测执行与结果回收。
这里涉及到3个关键点：
风险任务识别推荐。几百万的离线数据任务中，哪些真的存在风险，需要压测；
压测输入数据构造。用什么样的数据压测；
影子链路构建。压测产生的数据不能影响线上；
2.1 风险任务识别推荐
对所有离线任务进行压测，既浪费计算资源又浪费人力。利用任务运行元数据+风险模型召回，为业务方推荐需要压测的高风险任务。核心特征为：历史大促与日常运行时长与数据量的变化、任务本身日常运行情况、任务在整个数据链路中的情况、任务对业务的影响等
2.2压测输入数据构造
既便捷又灵活地提供压测输入数据构造方式，减少人工准备数据的过程。实际的压测数据生成能力与影子链路构造能力打通，在影子链路生成时就已经按照要求生成创建压测数据的任务，并添加依赖关系。
选择膨胀模式，根据原输入表数据，自动生成压测输入数据
选择替换输入表，则根据实际需求自主准备压测输入数据，灵活替换
2.3 影子链路构建
不同于实时流式计算靠消息监听与消费的方式形成上下游依赖关系，离线分布式计算实则是批处理，有明确的上下游依赖关系，这种关系体现在离线数据任务配置、调度执行等方面。
影子链路构建核心是根据所选任务的集合，自动分析其内在的依赖关系，保持原有上下游关系进行整体复制：代码内容复制，同时替换输入输出表；任务参数配置、依赖配置、优先级复制，最大程度还原生产环境的配置项；批量提交与发布。
若被压测任务的上游也在压测范围内，自动将上游输出的影子表作为该节点压测输入表，减少压测输入数据的构造消耗。
2.4 离线压测的应用实践
连续三年支持集团内多个BU业务包括天猫、淘宝、生意参谋、数据银行、数据公共层等大促离线压测。单次压测覆盖的数据量达万亿级，任务性能提前发现占比达到75%，通过压测的数据任务99%以上在大促中表现平稳。成本控制方面，利用一天中的资源低峰期进行压测，不产生额外压测成本；得益于工具化的完善，压测准备与执行在1天内即可完成。
数据应用提前预演
在大促活动正式开始前重要数据产品部分核心指标没有真实数据。例如：预售、活动商品加购、尾款支付、玩法逻辑等。如果不经过验证就上线，那么有些问题直到活动开始后才能发现，可能出现数据计算错误、数据展示不符合预期、数据产品报错。
常见的工程应用系统采用的预演手段，主要是构造测试商品、测试订单、测试账号，验证功能正确性，但对于数据产品而言，存在以下缺点：
大数据计算逻辑难以被验证
测试数据会被代码逻辑过滤
多模块多指标联动的测试数据构造难度大（先有订金行为才能有尾款支付行为）
系统服务有预发beta环境，但是数据链路没有
数据应用提前预演旨在提供业务数据提前测试方案，包括数据测试环境准备、预演数据构造、预演流程串接，验证实时&离线数据业务场景的质量和数据产品功能。整体方案如图所示：
1
预演链路
复用数据全链路压测的血缘分析能力和影子链路构建能力，为数据逻辑验证准备一个可测试的环境
数据服务化并提供可灰度能力，打通数据影子链路与系统服务的预发beta环境，从而搭建数据+产品完整的预演链路
2
预演数据
无论是实时还是离线，主要的预演数据来源有三种：历史大促峰值时段完整数据、日常线上数据、压测数据。将这些数据事先保存和偏移处理，为预演提供不同时段的完整真实数据，保证了数据产品各模块之间的联动。
3
预演流程
工具化方式将整个预演涉及的流程串接，其中核心提供了字段级的规则偏移能力，预演数据在灌入数据影子链路前可以自定义修改部分字段值，既不会被内部逻辑当做测试数据过滤掉，又能灵活地模拟特殊业务场景的逻辑验证诉求。
数据应用提前预演的解决方案中，最大程度的复用了数据全链路压测的底层能力，根据预演流程的需要将相关能力组装，本文不再展开介绍。
4
数据应用提前预演的应用实践
连续三年支持集团内核心决策数据产品、商家数据产品、媒体大屏等业务完成促前预演。包括：数据公共层、淘宝&天猫决策产品、生意参谋等，覆盖数千个核心指标的大促预演，提前发现问题60+（往年大促活动开始后才能发现的问题）。以媒体大屏为例，GMV数字背后有40+计算链路，一旦出现问题，可能会造成社会舆情风险。通过数据预演的方式覆盖85%以上的计算逻辑，累计发现10+以往0点数字起跳后才能发现的问题。成本控制方面，通过工具迭代完成流程化串接，只需要2人天即可完成数据应用场景的预演准备与执行。
数据变更管控检测
数据链路长依赖层级多，采集、加工、应用各个环节，无论是任务代码发布、运维操作、配置变更都有引入风险的可能。在大促期间，变更引入的小问题在峰值流量的冲击下都有可能被放大，从而导致影响整体的重大问题。如果任何时候都不变更对于系统来说是最稳定的，但这样一刀切的管控，业务团队会造成很大的影响，有损工作效率，增加风控成本。
数据变更管控检测的核心在大促期间或特殊时期，提供多样化定制管控规则和检测规则，减少低级变更问题引入、提升基础变更质量。整体方案如图所示：
1
管控形式
充分对接集团内数据开发平台，在数据任务的提交、发布、运行、运维流程中提供开放的检查器能力，通过流程拦截实现变更的管控能力
2
管控对象
场景化支持变更管控与检测能力。业务负责人、稳定性接口人，自定义管控范围、对象、生效时间，自主选择数据任务变更时需要检测的规则
3
检测内容
检测规则包括代码性能、语法规范、冻结&下线&回补等运维操作规范、配置检查、参数规范检查、依赖检查、代码评审&冒烟测试等质量规范。另外支持第三方检测平台通过API方式自定义检查规则，在变更管控流程中加入实现个性化的检测能力。
通过场景化定制对数据任务的任意变更都能覆盖基础的检测规则，保障了链路上所有变更的基础质量水位。
数据变更管控检测的解决方案中，核心打通集团内的数据开发平台、使用对应的API、复用上文提到的血缘分析等能力，结合不同业务对变更质量的要求不断丰富检测规则。相应的底层能力本文不再展开介绍。
4
数据变更管控检测的应用实践
连续2年，双11、618大促，支持集团内众多数据业务定制管控检测场景，包括：淘宝&天猫数据业务、本地生活业务、文娱业务等。覆盖1万+高优先级数据任务，累计拦截的风险变更500+，其中300+涉及资损场景的任务变更。成本控制方面，仅需一个人即可完成整个BU或者业务线的管控检测配置，提升基础变更质量。
展望未来
数据全链路压测未来会持续丰富压测场景，增加建站压测、业务单压等，以极小的人力完成全链路压测的前置验收工作以减少全链路压测次数和人力投入；数据应用提前演练将逐步日常化，将预演链路、预演数据、预演流程，更低成本地应用到日常数据全链路测试中。数据变更管控检测未来将串联数据测试与回归，将变更管控检测作为数据测试覆盖、数据质量回归的切入点与核心抓手。
鲁天龙老师完整演讲PPT获取方式：关注公众号后，消息回复”上海“即可获取
2023年QECon会议计划
更多会议内容可点击下方【阅读全文】进入大会官方网站查看